Generally, change of a system is conducted in such a manner that an administrator of the system creates a procedure manual to change states of components that configure the system to a requested state, and a change operator executes change operations according to the procedure manual. To correctly complete all the change operation, the change operations need to be executed in the correct order. The order of the change operations varies depending on the characteristics and combination of the components (hereinafter referred to as system components or simply components) that configure the system. Therefore, to correctly describe the procedure manual, deep understanding of the system and components is necessary, and a high level of expertise and enormous time are required.
There is a technique for formally expressing requirements regarding a change procedure for changing a state of a component according to state elements and a dependency relationship between the state elements. Here, the state element is an information group keeping information regarding a state of a predetermined object such as a certain system component and a method of changing the state all together. An example of the state element includes an identifier (hereinafter referred to as “id”) for identifying the state element, possible states, executable state transitions among the available states, a current state, and a request state, for an object. Note that the id of the state element can also be used as an id for identifying an object having information regarding the state of the state element and a method of changing the state.
FIG. 22 is a conceptual diagram of a certain state element “e”. In FIG. 22, “e” represents an id of the state element. Further, “s1” and “s2” represent states possibly taken by an object in the state element. “t1” and “t2” represent executable state transitions between the states possibly taken by the object in the state element. Further, “s1” represents a current state, and “s2” represents a request state.
In the present specification, as illustrated in FIG. 22, the entire state element is represented by a rectangle with rounded corners. Further, each of the possible states is represented by an ellipse. Further, the executable state transition is represented by a solid arrow between states. Further, the current state is represented by a double-line ellipse. Further, the request state is represented by a black ellipse. The state element illustrated in FIG. 22 can be regarded as expressing a change request for changing the target “e” from the state “s1” to the state “s2”. Note that, by use of a change procedure generation system of generating a change procedure on the basis of the state element expressing such a change request, the change procedure including necessary operations from the state element to the state transition “t1” can be derived.
In a case of changing any one of a plurality of objects in a cooperative relationship, a correct change procedure can be derived by defining a dependency relation between state elements of the objects.
FIG. 23 is a diagram illustrating an expression example of a change requirement of a system based on a plurality of state elements. In FIG. 23, the change requirement of the system necessary for starting middleware (MW) is expressed using two state elements. For example, the object system includes a virtual machine (VM) and middleware (MW) installed in the VM. An id of the state element targeting the VM is “VM” and an id of the state element targeting MW is “MW”. In state elements “VM” and “MW”, a state “F” represents a stop state, and a state “T” represents an operation state. As illustrated in FIG. 23, the transition from the state “F” to the state “T” in the VM is performed via start processing “boot” of the VM. Further, the transition from the state “T” to the state “F” in the VM is performed via stop processing “stop” of the VM. Further, the transition from the state “F” to the state “T” in the MW is performed via start processing “start” of a service of the MW. Further, the transition from the state “T” to the state “F” in the MW is performed via stop processing “stop” of a service of the MW.
Here, the MW is installed on the VM, and therefore the VM needs to be started in order to start or stop the service of the MW. Therefore, it can be seen that a procedure of performing a state transition of the MW while the VM is in the stop state is an error. To define constraint conditions for such change, in FIG. 23, dependency of the state element “VM” on the state “T” is defined for the state transition “start” and the state transition “stop” of the state element “MW”.
By use of the above-described change procedure generation system, the change procedure for changing the state of the desired object from the current state to the request state can be derived while such dependency is satisfied. In the example of FIG. 23, a procedure of changing the state of the VM from “F” to “T” and then changing the state of the MW from “F” to “T” is derived. More specifically, a change procedure of conducting the start (“boot”) of the VM, which is state transition processing for changing the state of the VM from “F” to “T”, and then conducting the start (“start”) of the MW, which is state transition processing for changing the state of the MW from “F” to “T”, is automatically derived.
A method of deriving a change procedure of a system based on state elements as described above is disclosed, for example, in NPL 1.